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Abstract 

The objective of the Environmental Control and Life Support System (ECLSS) 
Advanced Automation Project is to recommend and develop advanced software 
for the initial and evolutionary Space Station Freedom (SSF) ECLS system 
which will minimize the crew and ground manpower needed for operations. 
Another objective includes capturing ECLSS design and development 
Knowledge for future missions. 

This report summarizes our results from Phase I, the ECLSS domain analysis 
phase, which we broke down into three steps: 1) Analyze and document the 
baselined ECLS system, 2) envision as our goal an evolution to a fully 
automated regenerative life support system, built upon an augmented baseline, 
and 3) document the augmentations (hooks and scars) and advanced software 
systems which we see as necessary in achieving minimal manpower support 
for ECLSS operations. 

In addition, Phase I included development of an advanced software life cycle 
plan inpreparation for phase II and III, the development and integration phases, 
respectively. Automated knowledge aquisition, engineering, verification, and 
testing tools will be used in the development of the software. In this way, we 
can capture ECLSS development knowledge for future use, develop more 
robust and complex software, provide feedback to the KBS tool community, and 
insure proper visibility of our efforts. 
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Introduction Description 

The overall goal of the ECLSS Advanced Automation Project is to help develop 
a fully autonomous Environmental Control and LifeSupport System for the 
Space Station Freedom and future manned missions. We have broken this 
goal into the following more practical objectives: 

1 ) Analyze and document the ECLSS for automation candidates 
which, when deployed, would minimize crew and ground ECLSS 
operations. 

2) Propose and document a fully automated ECLSS by 
augmentation of the baselined design with advanced software. 

Present software hooks and hardware scars which will enable 
migration of the advanced software to the flight station. 

3) Develop, test, and demostrate on ECLSS hardware the most 
promising automation candidates using tools which maximize 
productivity in the acquiring, engineering, and storage of ECLSS 
knowledge. 

Our approach is to break the project into phases; analysis, development, and 
integration: 

Phase I/FY89 Analyze and document ECLSS Advanced 

Automation candidates, approach, and hooks 
and scars. 

Phase II/FY90 Aquire tools and ECLSS knowledge, develop 

prototype software, and test in a simulated 
environment. 

Phase III/FY91 Integrate the advanced software into the 

ECLSS advanced development testbed for 
concrete demonstrations of the advantages of 
knowledge-based systems diagnosis. 

The Johnson Research Center of the University of Alabama in Huntsville has 
completed the Phase I analysis of the ECLSS. 

Boeing Computer Services Artificial Intelligence Center (BCS/AIC) was brought 
on board late in FY89 as the engineering development contractor in Phases two 
and three. The AIC has taken part in, and reviewed the UAH work, and 
developed a detailed software life cycle plan for prototype development and 
integration. 

This presentation summarizes Phase I, gives status of Phase II, and presents a 
general look at our future plans. 
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* Project Goal: 

A fully automated Environmental Control and Life Support System.for the 
Evolutionary Freedom Station 

• Practical Objectives: 

1) Analyze and document the baselined ECLSS 

2) Document automated ECLSS: augmentation of baseline 

3) Develop prototype software and integrate with hardware 


• Approach 
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• Presentation Overview 

- Phase I Analysis Approach 

- ECLSS Software Domain Overview 

- Detailed FDIR Description 

- Detailed Water Quality Monitor Description 

- Automation Application Analysis 

- Overview of Major Hooks and Scars Analysis and Results 

- Phase II Development Status and Future Plans 

- Conclusion 



Phase I Analysis Approach Description 

The Phase I analysis report was generated by UAH in a manner similar to that 
depicted on the graph. We began by analyzing the ECLSS domain . As the 
ECLSS is currentlyin the preliminary design stage, our knowledge was 
generated from three general sources: 

• Applicable Space Station Freedom documentation such as the ECLSS, 

DMS, OMS, Architecture Control Documents (ACD's), Contract 
End Item Specifications, ECLSS component test plans, and 
design review presentations 

• Conference reports which discussed control of environmental 

processes using knowledge*based systems. 

• Interviews with ECLSS test and design engineers, scientists, and 

doctors 


The UAH team, consisting of environmental, chemical, process control, and 
artificial intelligence engineers, gathered some 140 documents and 
presentations (an appendix to the Phase I report lists these references). They 
then analyzed each document, determining areas in need of advanced 
automation and the resulting hooks and scars. 


Those software processes which were seen to be candidates for automation 
(and some new applications, not in the baseline) were listed. 

Evaluation criteria was generated and applied to each candidate in order to 
methodically discuss and document the pros and cons of development of each 
KBS application. 


From the prime candidate list, an application was picked for rapid prototyping, in 
order todevelop a feel for the resource requirements (speed and memory) and 
operating system functional interface required. We prototyped a CLIPS based 
system which monitors and diagnoses faults in the Potable Water Recovery 
Subsystem. We found we that more than a production system tool was needed 
for adequate automation of our system (more on this in the results section). 


The baselined ECLSS design was compared with the requirements of our 
candidateadvanced automation systems in order to drive out a list of hooks and 
scars. 
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Phase I Analysis Approach 





ECLSS Software Domain Overview Description 

The ECLSS Station Manager, 1 .0) contains four functional software 
components which: 1.1) Maintain ECLSS configuration data, 1.2) coordinate 
the ECLSS among elements and, 1 .3) control 02N2 pressure. 02N2 Pressure 
Control, Number 1.3) is an ACS function which is included in the ECLSS station 
manager software because it must monitor atmosphere constituents throughout 
the Station. 

1.2) coordinating the ECLSS among elements requires expert knowledge of the 
ECLS System. This function is responsible for Inter-Module Ventilation (IMV), 
inter-module cabin air, and inter-module potable and hygiene water control. 

The inter-module air flow problem should be solved during Expanded ECLSS 
testing when a "race track" of element mockups will be used to make sure no 
instabilities exist in controlling the blowers and valves which semi- 
independently push air around the station. The function coordinating the 
ECLSS among elements function will be defined in greater detail during testing. 

2.0) , the ECLSS Element Supervisor contains many candidate automation 
processes. It includes 2.1), distributed subsystem control, a generic name for 
those subsystem functions which require distribution throughout the lab, such 
as Fire Detection sensor monitoring and verification, Avionics air cooling and 
distribution control, etc.... The process control software loops for these functions 
will reside in the ECLSS Element Supervisor. 

2.2) Inter-subsystem flow control is similar to 1.2) ECLSS coordination among 
elements in that the total responsibilities of this function will be derived during 
testing. Its responsibilities will include control of C02 transfer from the 4BMS to 
the Bosch, venting from the Bosch to the TCC, water transfer from the Bosch 
and the THC assembly to the potable water processor's raw water tank, and 
hygiene water transfer from the hygiene water processor to the water 
electrolysis unit. 

2.3) Off-line subsystem FDIR is a monitoring and diagnosis function. It will be 
explained later as a prime candidate for an advanced automation approach. 

2.4) Component performance and trend analysis is in the ground ECLSS 
sustaining engineering environment, though some of its functions will migrate 
on-board as DMS resources permit. This function records and analyzes trend 
data on the performance of ECLSS pumps, valves, heaters, and filters which 
will be used to predict faults, maintain system health, and schedule 
maintenance procedures. Research in chemical and microbial interactions may 
allow this function to predict and maintain proper chemical and microbial 
balances throughout the regenerative life support system. 

3.0) Real-time Process Control Software consists of process control algorithms 
in each subassembly, real-time fault detection, and built in tests (BIT) for each 
subassembly. 
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Real Time and Off Line FDIR Description 

There is a duplication of Potable Water Recovery (PWR), Hygiene Water 
Recovery (HWR), and Air Revitalization (AR) subsystems for redundancy. There 
are actually four of these subsystems, two in the Habitation Module, and two in 
the Laboratory Module. Two of the four are running in nominal operations to 
support an eight man crew. 

2.3) Real-time and Off-line FDIR has been split into its two components, 2.3.1) 
Real-time Subsystem Fault Detection, and 2.3.2) OfflineSubsystem Fault 
Isolation & Recovery. 

The schenario depicted is a failure in PWR subsystem A. This failure is 
detected by 2.3.1) Real-time subsystem fault detection, which monitors the 
sensor values of the running PWR subsystem and compares these to expected 
values. This system is to be developed as part of the baseline using algorithms 
implemented in Ada with the support of ground personel. 2.3.1 ) detects the fault 
and informs 2.0) the ECLSS Element Supervisor which instructs PWR 
subsystem B to initialize and PWR subsystem A to change modes to 
diagnostics. The ECLSS Element Supervisor also starts another software 
process, 2.3.2) Offline Subsystem Fault Isolation and Recovery, passing it the 
name of the subsystem to diagnose. 

2.3.2), The off-line fault isolation and recovery process inpects the status of the 
offline (not running but in diagnostic mode) PWR subsystem, sends commands 
and inspects the responses of the faulty subsystem if the failure is not 
immediately apparent. The off-line fault isolation and recovery procedure may 
instruct the faulty PWR subsystem to perform built in tests, or more advanced 
tests. With the help of ground support and maybe some manual crew 
procedures, the fault is isolated and a recovery recommendation is formulated 
and sent to the ECLSS Station Manager through the ECLSS Element manager. 

Advancements in the maturity of knowledge based real-time monitoring and 
diagnosis systems indicate that these software processes are prime candidates 
for advanced automation development. Autonomous ECLSS subsystem RT & 
OL FDIR processes could utilize an internal model of the subsystem under test. 
Implementation of FDIR processes based on internal causual models show 
strong promise in knowledge based systems for process control diagnosis. 
Model aqcuisition should start early in the design process, because later 
implementation may prove too costly. 
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Water Quality Monitor Description 

The second major automation candidate is the Water Quality Analysis 
processwhich includes the process control water quality monitor (PCWQM), not 
shown on this graph, 4.1) the batch water quality monitor (BWQM), and 4.0) the 
ground basedchemical and microbial analysis process which is not shown here 
but is on the ECLSS Domain Functional Schematic. 

There are two types of water quality monitors, the PCWQM, and the batch 
water quality monitor (BWQM). There is a PCWQM associated with each 
potable, hygiene, and urine pretreatment system. The PCWQM gives near real- 
time continuous readings for pH, conductivity, iodine concentration, and total 
organic carbons (TOC) for the product (output) water of each system. If the 
product water does not match the required specifications for these values, it 
returns as raw, or input water to the systems. 

It is important to understand the limitations of the PCWQM data. 

The TOC readings detect the presence of organic compounds but cannot 
differentiate between compounds or determine their source. 

Therefore, periodic manual water sampling and manual analysis will be 
necessary. The flight and ground batch water quality monitor (BWQM) will 
provide more complete water quality data. 

The batch water quality monitor is a mass spectrometer (developed by Perkin 
Elmer) which requires periodic manual sampling via manual sample ports (SP) 
in the potable and hygiene product water lines. The on-board BWQM allows 
the crew to perform tests more frequently than 90 days, when a shuttle flight will 
return samples for more extensive ground testing. Such testing will include 
culture growth, a visual inspection, and qualitive judgement by an expert using 
a microscope to check for various micro-organisms. 

Data from the on-board BWQM will be available on the DMS for on-board 
processing and downlink. Currently, there are no plans to automate the 
sampling procedures or data analysis. 

A technique may be needed in the future to automate BWQM sampling of 
potable and hygiene water. Further, research into automated analysis of mass 
spectrometer data may enable further automation of this process. This is 
required to be a real time analysis, on the order of seconds, to feed back into a 
more advanced control system which will use the data in adjusting a more 
flexible process control system. This information will also be used to decide if 
the water was drinkable or okay to wash with. 

There has been effort in the medical industry to use many types of analysis 
including flow cytometry, solid state chemical sensors, and pattern recognition 
software to isolate specific organic constituents in real-time ( the UAH report 
explores some of this promising research. 
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Automation Application Analysis Description 

The objective of this analysis is to determine, based on specific criteria, which 
function in the ECLSS domain to automate. 

1.2) ECLSS Coordination among elements and 2.2) Inter-subsystem flow 

control. These application are not well understood, expanded ECLSS 
testing will be required. The baseline application will be accomplished 
with enhanced instrumentation and traditional algorithmic architectures 
(Ada tasks and Unix operating system on a 80386-based computer.) 

2.3) Real-time and off-line ECLSS subsystem FDIR functions meet all the 

criteria: 

• Implementation of an advanced automation approach to subsystem 

FDIR will reduce crew and ground maintenance times. 

• The processes can be implemented on ground and migrated on board. 

• These applications are well understood; the knowledge required is in 

the designs and models of the subsystems. 

• The processes cannot be accomplished with enhanced instrumentation 

and traditional algorithmic architectures. 

• A model oriented approach would minimize the use of sensors for 

subsystem FDIR and resolve the problem of bad or missing sensor 
data. 

• Technology for advanced automation approach is sufficiently mature 

due to the emerging capabilities of model based reasoning 
systems and tools. The subsystem control latencies are 
sufficiently long to allow implementation of real-time advanced 
fault analysis. 

2.4) Component performance and trend analysis is already in the baseline for 
ground systems and will be migrated onboard after assembly complete. Some 
health maintenance functions may require a knowledge based approach. The 
application is not well understood at this time. 

2.5) Automatic and semi-automatic fire suppression is already in the baseline. 

4.0) Automatic chemical and microbial water analysis is not well understood. 
Research is required for this application. Technology does not yet exist for 
automated extensive analysis of mass spec data, and symbolic and/or neural 
net processing architectures onboard. 


Automation Application Analysis 


Criteria For Application Selection 

A. Implementation of an advanced automation approach will reduce crew 
and ground maintenance times. 

B. Process can be implemented on ground and migrated on board. 

C. Application is well understood. 

D. Cannot be accomplished with enhanced instrumentation and/or 
algoritmic architectures. 

E. Technology for advanced automation approachis sufficiently mature. 


Candidate Applications Matching Criteria 

1 .2) ECLSS Coordination among elements ABE 

2.2) Inter-subsystem flow control ABE 

2.3) Real-time and off-line ECLSS subsystem FDIR ABCDE 

2.4) Component performance and trend analysis ABDE 

2.5) Automatic and semi-automatic fire suppression CE 

4.0) Chemical and microbial water analysis ABD 


Hooks and Scars Analysis Results Overview Description 

The following are the major software hooks and hardware scars necessary for 
evolution to a more autonomous ECLSS. Prototype and baseline ECLSS 
development will produce more necessary augmentations. 

• The advanced subsystem FDIR requires component sensors to be available 

from the Runtime Object Data Base (RODB) within 1 second with the 
assumption that the subsystem's control loops have a latency of 5-10 
seconds. This allows real-time fault detection and fault preventive 
reconfiguration to use 3-8 seconds because communication with the 
ECLSS subassembly monitoring process is expected to take about 2 
seconds. 

The software design of the RODB must meet the requirements of process 
location transparency and performance. 

Our analysis indicates that early capture of design knowledge using 
design knowledge capture tools such as AQUINAS and object oriented 
model-based reasoning tools such as KATE and ART/Ada would 
increase our automation proficiency. We suggest these tools be added 
to the SSFP Software Support Environment 

ECLSS leak detection can either be implemented using extensive leak 
detection instrumentation, or by designing subsystems using advanced 
engineering modeling and design tools which automate determination of 
optimal placement of leak detection sensors. 

Model-based reasoning approach to subsystem FDIR would allow 
minimal use of explicit leak detection sensors by inferring leaks using the 
baseline process control sensors. 

• Advanced water quality monitoring will require scarring of the baseline design 

for future automatic transfer of potable and hygiene product water to the 
batch water quality monitor. This would be very expensive to implement 
without the scarring built in to the initial station. 

• Research in automated analysis of Water Quality Monitor output is needed. 

Fast processing will be needed in order to implement real time chemical 
and/or microbial analysis in the life support control system and to quickly 
determine if the water is drinkable or okay to wash with. 

Intelligent instrumentation systems are needed for real time and inline 
chemical and microbial analysis. 

Onboard processing may require fast symbolic and/or neural net 
processing architectures. 

• Certain aspects of inter-element coordination and inter-subsystem flow control 

are candidates for a production system approach. We also explored the 
use of a blackboard architecture to solve the problems of these functions. 
They will require expert system support functions in the Application 
Program Interface Definition (APID), expert system development tools in 
the SSE, and automated knowledge aquisition systems in the SSE. 


Hooks and Scars Analysis Results Overview 


• Requirements for advanced subsystem FDIR: 

1) Component sensors available from the Runtime Object Data Base 

(RODB) within 1 second. 

2) Software process location transparency. 

3) Design knowledge capture tools and object oriented knowledge 

based system development tools available in the Software 
Support Environment (SSE). 

4) Engineering modeling and design tools which automate determination 

of optimal placement of leak detection sensors. 


• Requirements for advanced water quality monitoring: 

1) Scarring for automatic transfer of potable and hygiene product water to 

the batch water quality monitor 

2) Research in automated analysis of water quality monitor output 

3) Research in realtime chemical and microbial analysis 

4) Probable: symbolic and/or neural net processing architectures 

onboard 


• Requirements for advanced ECLSS inter-element coordination 

1) Expanded ECLSS domain testing. 

2) Knowledge based system support functions in the Application 

Program Interface Definition (APID) 

3) Knowledge based system development tools in the SSE. 

4) Automated knowledge acquisition systems in the SSE. 


• Requirements for inter-subsystem flow control: 

1) Expanded ECLSS domain testing. 

2) Blackboard software architecture application to the intersubsystem 

flow control problem. 

3) Blackboard development tools in the SSE. 

4) Automated knowledge acquisition systems in the SSE. 



Development Status and Plans Description 


Slaius 

We have used Aquinas for knowledge acquisition on the potable water 
processor tradeoffs. 

ART/Ada has been installed. 

Development of the model based Water Recovery and Air Revitalization 
Diagnosis prototype using KATE is on-going. 


Plans 

Demonstration of the KATE based Water Recovery Diagnosis Prototype using a 
simulation of the Water Recovery Subsystem. in the summer of FY90. 

Demonstration of the ART/Ada based Potable Water Recovery Diagnosis 
Prototype was scheduled for 2/90 but will be delayed until this spring. Possible 
use of TAE+ as the interface. 

Phase III will demonstrate the Water Recovery Diagnosis Prototype using actual 
ECLSS Water Recovery Subsystem hardware. 

Also in Phase III we will begin development of the Air Revitalization Diagnosis 
prototype which will contribute to the overall Regeneration Analysis and 
Diagnosis system. 

A fourth Phase is needed to produce results on expanded ECLSS test data and 
to complete the Regeneration Analsys and Diagnosis system. 



Development Status and Plans 


Status 

• Knowledge Acquistion 

• ART/Ada beta test software installed 

• Model based water recovery subsystem diagnosis development using KATE 

Plans 

Phase II 
June/FY90 

August/FY90 

Phase III 
August/FY91 

FY91 

Phase IV 
FY92 


Demonstration of the Potable Water Recovery Diagnosis 
Prototype port to ART/Ada 

Demonstration of the model based Water Recovery 
Diagnosis Prototype using a simulation of the Water 
Recovery Subsystem 


Demonstration of the model based Water Recovery 
Diagnosis Prototype using actual ECLSS Water Recovery 
Subsystem hardware 

Development and integration of Air Revitalization Diagnosis 
with demonstrations using simulation and actual hardware 
Preliminary Integration of a Regeneration Analysis and 
Diagnosis system 


Results on expanded ECLSS test data 

Completion of the Regeneration Analsys and Diagnosis 

system. 


Conclusion 


P h as e I re sults: 

• ECLSS Advanced Automation Candidates. 

• ECLSS hooks and scars analysis tor growth to advanced automation. 

• Prototype of the Potable Water Recovery FDIR Knowledge Based System. 

• Advanced software life cycle plan for development and integration. 

Phase II Status : 

• Knowledge Acquisition using Acquinas. 

• ART/Ada port of the CLIPS Water Recovery Diagnosis prototype in progress. 

• KATE - Based Potable Water Recovery Diagnosis prototype 
Phase II Dev elopment: 

• Demonstrateion using simulation of the Water Recovery Subsystem. 

• Continued ART/Ada beta testing. 

Phase III Plans: 

• Demonstration using Water Recovery Subsystem hardware in testbed. 

• Integration of Air Revitalization Diagnosis knowledge 

Phase IV Plans: 

• Demonstration of Regeneration Analysis and Diagnosis system on expanded 

ECLSS test bed. 



Conclusion Description 


The results of Phase I of the ECLSS Advanced Automation project were 
discussed. These results include: 

Analysis and documentation ofthe ECLSS Advanced Automation 
Candidates which support our Phase II development, and baseline 
system design augmentations required for easier growth to automation. 

Development of a prototype Potable Water Recovery Diagnosis rule 
based system which helped in our requirements analysis and will be 
used as a starting point for future development. 


Phase II development status was discussed and included the use of AQUINAS 
for knowledge acquisition. ART/Ada and KATE for development of the ECLSS 
Water Recovery and Air Revitalization Diagnosis software. 


Phase II will produce a Water Recovery Diagnosis Prototype which will be 
demonstrated using a simulation of the Water Recovery Subsystem. 


Phase III will demonstrate the Water Recovery Diagnosis Prototype using actual 
ECLSS Water Recovery Subsystem hardware. Also in Phase III we will begin 
development of the Air Revitalization which will contribute to the overall 
Regeneration Analysis and Diagnosis system. 


A fourth Phase is needed to produce results on expanded ECLSS test data and 
to complete the Regeneration Analsys and Diagnosis system. 



